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[57] ABSTRACT 

A computerized system offers a uniform platform for con- 
ducting electronic transactions in multiple different environ- 
ments. The system includes a portable, multi-purpose, inte- 
grated circuit (IC) card and complimentary computer 
software which enables access and management of resources 
maintained on the IC card. The software runs on a user's 
personal computer, empowering the user to initialize the IC 
card, configure the card with the resources that the user 
wants to maintain on the card, and to manage those 
resources. The software enables the user to generate private/ 
pubhc key pairs and establish or change passcodes for 
access to the card resources. The IC card itself provides the 
electronic vehicle for securely transporting the user's private 
keys and certificates without exposing them in plaintext 
form. The IC card is designed with enough processing 
capabilities to perform rudimentary cryptographic functions 
so that the private keys may be employed for signing or 
encryption without ever being released from the card. 
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SYSTEM AND METHOD FOR iiy are becoming more imponant as reliance on computer 

CONFIGURING AND MANAGING networks increases. In modem network environments, iden- 

RESOURCES ON A MULTI-PURPOSE tification and authentication are commonly used in access 

INTEGRATED CIRCUIT CARD USING A protocols aimed at preventing unauthorized users from gain- 

PERSONAL COMPUTER 5 ing access to resources and services provided by the net- 

TECHNICAL FIELD "^ork. Typically, a user identifies himself or herself to a 

computer using a login dialog in which the user enters a 

This invention relates to integrated circuit (IC) cards, such descriptive and secret code name. The authentication pro- 
as smart cards, PC cards, and the like, which are capable of cess running on the computer validates the user based upon 
being used for multiple different applications. This invention lo this confidential code name. Once validated, the user is free 
further relates to systems and methods for initializing, to roam the computer and network for resources and ser- 
configuring, and managing various resources maintained on vices. Unfortunately, the password authentication process 
the IC cards. This invention also relates to the secure often falls short of providing adequate security or user 
management and transportation of cryptographic-related authentication. The password protocol, by itself, is well 
resources, such as keys and certificates, from one location to 15 known to be weak and conducive to successful illegitimate 
another. attacks. 

BACKGROUND OF THE INVENTION The problems inherent in password approaches has given 

Computers are playing an ever increasing role in day-to- ^^^0^ variety of products which perform user authcnti- 
day personal management. Individual users keep appoint- ^uch products typically employ cryptographic tech- 
ment schedules, track bank and credit card accounts, manage °^l°gy ^° combmation with hardware token devices. These 
investment portfolios, reserve travel accommodations, trans- ^^^^^ typically pre-configured by the manufac- 
act business, order products, and submit payment aU dec- dehvered to the user and replace the logm pass- 
tronically from their own computers. This revolution is "^'^^ ^ "^^^^ ^^^^^^ ^"^^^^ challenge- 
being spawned by the combined phenomenon of rapid and ^^*P°"^ protocol. WhUc this technology is adequate for 
wide deploymem of personal computers in both business access control on an enterprise network (i.e., a local network 
and home environments, explosive growth in interconnect- ^ ^'^^^^^ ^"^^^y)' " ^ particularly scalable 
ing these personal computers to networks and online to public networks used by a large user population. This is 
services, and dramatic increase in the deployment of retail ^^^^^^ ^^1^^°^^^ °" ^ centralized access control server 
terminals or kiosks based on PC technology. 3^ ^^^^^ knowledge of aU the tokens issued lo vahd users. 

As part of this trend, businesses have identified significant Another problem which existing hardware tokens has 

opportunities for electronic commerce, not only with other ^^^^ generation and management of key values. "Keys" are 

businesses, but also through direct access to the consumer. * numerical value, often expressed digitaUy as a number of 

Merchants are selUng wares in an electronic marketplace bits, which are used in cryptographic algorithms that encrypt 

which enable users to shop and purchase goods using their 35 decrypt messages. The keys are uniquely associated 

computer. For instance, many merchants are developing web ^ particular identity, such as a user or a computer, 

sites that allow users to browse products over the Internet. Configuring millions of devices, each with its own unique 

Payment and settlement following any purchase are likewise k^V^, would be a huge processing task for the manufacturer, 

handled electronically among the merchants, their banks, resulting in a significant increase in the cost of the hardware 

any credit companies, and the purchasers' banks. ,q ^^^i^®* ^^^^ * security standpoint, another problem is that 

One consequence of this revolution is a growing demand the manufacturer becomes a centralized point of attack in 

for high data security and for high assurance in user iden- ^^^^^^ ^^^^^ ^^^^^^ ^"^"^P^ to steal private key 

tification and authentication. In an electronic marketplace, ^formation. Another problem concerns replacement of 

there is no facc-to-facc transaction in which security is ^^y^- ^nce a key has exhausted it useful life, the manufac- 

ensured by the presence ofboth parties and authentication of 45 ^^^^ f ^^^^ler issue new devices with new keys or 

the consumer involves personal recognition or quick veri- reconfigure o d devices to change the keys. Once again, this 

fication of a corroborating piece of identification (i.e.. a f extremely difficult, expensive, and inefficient task m a 

credit card or a driver's license). Rather, in an electronic ^^^^^ system. 

arena, the consumer might live in one state or country, while Accordingly, there is a need to develop an open identifi- 

the merchant resides in another, and the two parties never 50 ^^^^^^ authentication architecture that does not rely on 

meet in person. proprietary or customized hardware devices. 

For an electronic marketplace to flourish, consumers and In addition to identification and authentication, the elec- 

merchants must believe that information being exchanged tronic arena also requires secure data transmission over an 

between them is secure. They must also trust that the other insecure public network (e.g., the Internet). Cryptography 

party is legitimate. Moreover, each party must also have 55 has evolved in the electronic setting as a means to securely 

some assurance that the information received from the other transfer information over a communication system that is 

party did in fact originate at the other party (and not an presumed to be insecure. Cryptography provides the neccs- 

impostor) and that the information has not been subse- sary tools to digitally secure sensitive is and valuable 

quently altered or tampered with by an intruder. electronic messages in a manner that insures privacy 

Accordingly, security, identification, authentication, and 60 between the sender and recipient of the communique, even 

information validity are important to the full development though the message is subject to interception on the insecure 

and acceptance of an electronic marketplace. Furthermore, communication system. 

these capabilities must be readily portable by the end user in Through use of both public key (or asymmetric key) 
a manner which facilitates access to the electronic market- cryptography combined with secret key (or symmetric key) 
place from a variety of locations. ^5 cryptography it is possible to address the above require- 
Even outside of the commerce environment, the same ments. To initiate a secure electronic transaction between 
themes of security, identification, authentication, and valid- two individuals, one can use an authentication protocol 
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based on public key cryptography. This protocol will result "Bsafe libraries" by RSA Data Security Inc., "X/Open 

io the exchange of pub lie key certificates and data encrypted CAPI", and "PKCS/T. However, each of these systems 

with a private authentication key between the two users. The permit direct access of the application to the keying material, 

certificates contain a party's identification, the party's public There is no protection of these cryptographic resources from 

keys (typically both a authentication or signature key and a 5 electronic attack. Furthermore, the Bsafe system, which is 

key exchange key wiU be used), and is digitally signed by a most widely used cryptography system, directly attaches 

trusted certifying authority. Upon receipt of the certificate, the cryptographic code to the application. There is no 

each party validates the certifying authority's signature contemplation of protecting the keys from ignorant or mali- 

(using their pubhcly avaUable key). They can then use the ^^^^^s from other software appUcations. 

public key m the certificate to vahdate the authentication , . , 

data provided by the other party, which was encrypted with Accordingly, there is a need to a develop a system that 
their private key. Once the validation is complete, they have empowers the user with the tools to securely store and 
high assurance they are in communication with the indi- manage cryptographic keys and certificates along with criti- 
vidual named in the certificate. cal application data used with these assets to conduct 
To securely exchange messages they can use a combina- electronic transactions. Simply keeping private keys stored 
lion of both public and secret key cryptography. To send a in the user's computer may not adequately protect them 
secure message, the sender will generate a secret key and use fi"om such malicious applications that attempt to locate and 
this to encrypt the message using a secret key algorithm. expose the user's private keys. Moreover, designing specific 
Encryption transforms the message from plaintext into some hardware/software solutions for every data exchange appli- 
meaningless ciphcrtcxt that is not understandable in its raw cation is not particularly useful or workable for a broad 
form and cannot be deciphered by an eavesdropper. The 20 public system with millions of users, 
secret key is then encrypted using the recipients pubUc key j^^aUy, it is desirable to develop a platfonn which sup- 
exchange key. Both the encrypted key and encrypted mes- ^ ^^^^^^^ applications that a user might 
sage are then sent to the recipient. Furthennor^, to ensure ^^^^rtake. For instance, it would be convenient and efficient 
that the message IS not altered m any way, or IS replaced, the r t ,c * i_ j • j 1 . • 
, ^ J- •* 11 • *c • A, • for the same platform to be used m conducting electronic 
sender may also digitally sign the message using their 75 ^1 .1. r 

. . . , ^ ^ * ° commerce over a network, or authenticating a user for 

private signing key. - ^ , , . , 

, T • * r *u • J .J *u • • point -or-sale transactions, or managing a user s bankmg and 
Upon receipt of the signed encrypted message, the recipi- ^ . , ' . . . - »■ . 
ent first decrypts the secret key using their private key "^^^^ ^^^^^^^"i^ application. Most 
exchange key. They can then decrypt the message using the «f ^^^^^ applications require access to the user s certificates 
secret key and the same secret key algorithm which trans- ,0 '^ese different applicaUons typically 
forms the message from its ciphertext back to its plaintext, i^^^l^^ interaction with different computers, such as the 
Only the recipient is presumed to have the ability to decipher ^^^^'s own computer, an employer's computer, a banking 
the message since only the recipient has possession of its a° electronic ticketmg machme, and so on. 
private exchange key. The recipient verifies the authenticity To support multiple applications, the platform must 
of the sender's digital signature using the originator's public 35 enable a user to transport certificates and keys from one 
signing key (which it received in the originator's certificate) application to another in a secure manner. This would permit 
to assure itself that the contents are from the legitimate the user, for example, to gain access to his/her bank accounts 
sender and have not been subsequently altered. in a banking context, to exchange information with a col- 
Encryption, decryption, digital signing, and verification league electronically over a public network in a secure 
are therefore the principal cryptographic primitives that are 40 manner, and to digitally sign a purchase order in an elec- 
used in an electronic network setting to facilitate the Tronic shopping context. It is inadequate to transport the 
security, privacy, authenticity, and integrity of information certificates and keys on a memory disk as theft of the disk 
being exchanged. would compromise the keys. Even encrypting the keys 
The secure information exchange is jeopardized, before loading them onto the memory disk would not prove 
however, if the private keys are discovered through theft or 45 ^^^P^"^ ^'^^^"^ ^^y^ '^''''^^ eventually be decrypted at 
user mishandfing. The private keys must be kept confidential ^0°^^ ^'"^^ f^^"^^ P^^o^n^ ^ cryptographic function, 
to ensure security. However, in the computerized network always leaves a pomt where the private keys are 
setting, there are potential hazards of using private keys in available in unencrypted fomiat and thus, exposed to copy- 
the cryptographic functions within available personal com- "^S or unauthorized use. 

pulers or workstations. Since the functions are carried out 50 Accordingly, another design goal is to provide a multi- 
electro nically, the user might assume the cryptographic application platform which offers secure storage and trans- 
routines are operating as expected, yet not be aware of portation of private keys for use in different application 
ignorant or sophisticated electronic attacks. Careless appli- contexts, without jeopardizing or exposing the private keys, 
cations might use cryptographic exchange or signature keys Given these goals, there are countervailing concerns that any 
in ways that jeopardize the key's secrecy. Moreover, mali- 55 solution be cost effective, highly reliable, and diflGcult to 
cious applications might even deliberately compromise the compromise from a security standpoint, yet readily tailor- 
user's secrecy, or worse, perform unauthorized crypto- able to a user's needs and preferences, 
graphic operations. For instance, a malicious application „, 

migh. attemp. to decrypt the user's secret files and transmit SUMMARY OF TOE INVENTION 

them to some adverse party. Another situation might involve 60 This invention provides a uniform platform for conduct- 

an application attempting to digitally sign notes or 10 Us on ing electronic transactions in multiple different environ- 

behalf of the user without the user's knowledge or consent. ments. The platform is based upon use of a portable, 

A computer implemented cryptographic system must there- multi-purpose, integrated circuit (IQ card and complimen- 

fore provide the needed security to prevent attack from tary computer software which enables user access and 

poorly devised or malicious applications. 65 management of resources maintained on the IC card. The 

Today, there are several electronic systems that provide software runs on a user's personal computer, empowering 

cryptographic services in the computer forum. These include the user to initialize the IC card, configure the card with the 
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resources that the user wants to maintain on the card, and to 
manage those resources. The software enables the user to 
generate private/public key pairs and establish or change 
passcodcs for access to the card resources. The IC card itself 
provides the electronic vehicle for securely transporting the 
user's private keys and certificates without exposing them in 
plaintext form. The IC card is designed with enough pro- 
cessing capabilities to |>erform rudimentary cryptographic 
functions so that the private keys may be employed for 
signing, encryption, and decryption without ever being 
exported from the card. 

More particularly, one aspect of this invention pertains to 
a system having a multi-purpose IC card, a card reader 
which interfaces with the IC card to transfer information to 
and from the IC card, and a computer coupled to the card 
reader to control the information transfer between the card 
reader and the IC card. As an example implementation, the 
system can be implemented as a home computer, equipped 
with a card reader, and a generic smart card owned by the 
user. 

The system further includes various applications which 
execute on the computer, or more specifically, which run on 
the computer's operating system. For example, the appUca- 
tions might include a banking apphcation, which is orga- 
nizes the user's finances in conjunction with a particular 
bank; or an electronic commerce application, which allows 
the user to shop and purchase products over a public 
network; or a travel application, which permits the user to 
make vacation reservations; or an entertainment application, 
which enables the user to purchase tickets for entertainment 
events; or a gatekeeper application, which oversees access 
onto the network of the user's employer. In any one of these 
contexts, the application might require access to certain 
resources maintained on the IC card. 

The system further includes an application interface 
which executes an the computer to implement each appli- 
cation and to provide services which facilitate access to the 
resources on the IC card that are requested by the apphca- 
tion. The application interface is preferably implemented as 
a service layer for the operating system, and is securely 
integrated with the operating system via mutual authentica- 
tion procedures. The application interface supports three 
distinct types of services. These include (1) configuration 
services which permit a user to initialize and configure the 
IC card with those resources tailored to the user*s 
preferences, (2) security services which enable access to the 
cryptographic functionality on the IC card, and (3) resource 
management services which permit the user to manage the 
storage provided by the IC card. 

In one implementation, the application interface com- 
prises a cryptographic services module and a card manage- 
ment services module. The cryptographic services module 
implements cryptographic functionality for the application. 
The cryptographic services module uses cryptographic 
resources maintained on the IC card and supplements this 
with software services. When the appUcation requests a 
cryptographic function, the cryptographic services module 
communicates with the IC card to have the IC card support 
the cryptographic function. TTie IC card lends support with- 
out exposing the cryptographic resources maintained 
thereon. As an example, if the application requests a digital 
signature on a message, the application calls the crypto- 
graphic services module to hash the message to produce a 
digest and passes the message digest to the IC card. The IC 
card then digitally signs the digest using the user's private 
signing key and returns the signed digest to the application 
interface without exposing the signing key. The IC card can 
also assist in encryption, decryption, and authentication. 
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The card management services module implements the 
administration functionality for the appUcation for manag- 
ing resources maintained on the IC card. When the appli- 
cation requests performance of an administrative task on the 

5 IC card, the card management services module communi- 
cates with the IC card to perform the administrative task 
requested by the appUcation. For example, the card man- 
agement services module might support administrative tasks 
such as initialization of the IC card, generation of crypto- 

10 graphic keys, passcode configuration, and management of 
the IC card storage capabiUties to hold certificates, and 
assets. 

Another aspect of this invention is a card manager user 
interface (UI) which presents different graphical dialog 

1^ screens to assist the user in managing her card resources. 
The card manager Ul is very valuable from a usability 
standpoint. It provides a consistent presentation and method 
for managing the IC card resources which is independent of 
the appUcations being supported. The card manager UI 

^0 allows the user to examine the resources of the card by using 
icon representations of the resources. The user can configure 
his/her card to add or remove resources simply by manipu- 
lating the graphical icons. The card manager UI also enables 
the user to initiaUze the IC card, and change passcodes for 

25 accessing the IC card. 

Another aspect of this invention concerns the IC card 
itself. The integrated circuit (IC) card has a processor, a data 
I/O port controUed by the processor to receive and output 
data, a RAM, a ROM, and a programmable data memory 
(example EEPROM or Flash memory). Such cards are 
available from multiple sources and in several form factors. 
Card-based software supports the functionality required, and 
interfaces, provided by the software running on the PC. This 
card software provides for programmable data memory 
partitioned into a pubUc storage and a private storage. 
Confidential information, such as private keys, are main- 
tained in the private storage. Non-confidential user 
information, such as standard medical data, can be kept in 
the public storage. The processor is configured to access the 
private storage of the data memory only after the processor 
verifies a passcode supplied by the user. Conversely, the 
processor is configured to access the pubUc storage and 
output its contents without requiring receipt and verification 
of the user passcode. The partitioned storage and access 
protocol promote security of the cryptographic keys. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The same numbers are used throughout the drawings to 
50 reference like elements and features. 

FIG. 1 is a diagrammatic illustration of a system having 
a network -attached computer with integrated circuit (IC) 
card and reader. 

FIG. 2 is a block diagram of a software/hardware archi- 
55 lecture for the FIG. 1 system. 

FIG. 3 is a block diagram of an IC card. 

FIG. 4 is a diagrammatic illustration of a graphical dialog 
screen generated according to a card manager user interface 
executing on the computer. 

FIG. 5 is a diagrammatic illustration of another graphical 
dialog screen generated according to the card manager user 
interface executing on the computer. 

FIG. 6 shows a diagrammatic illustration of a card-based 
65 system which permits secure transportation of cryptographic 
keys, certificates, and digital assets from an application at 
one cite to another application at another cite. 
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FIGS. 7-12 present a flow diagram of a method for 
conducting an electronic purchase transaction using the IC 
card-based system. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The following discussion assumes that the reader is 
familiar with cryptography. For a basic introduction of 
cryptography, the reader is directed to a text written by 
Bruce Schneier and entitled "Applied Cryptography: 
Protocols, Algorithms, and Source Code in C," published by 
John Wiley & Sons with copyright 1994, which is hereby 
incorporated by reference. 

FIG. 1 shows a computer system 10 having a computer 12 
and a multipurpose integrated circuit (IQ card 14. The 
computer 12 includes a central processing unit (CPU) 16, a 
monitor or display 18, and a keyboard 20 (or other input 
device). The computer 12 is connected to a network 22 via 
a cable or wireless connection represented by line 24. The 
network 22 can be a data communications network including 
a wire -based network, such as an enterprise network (e.g., a 
local area network for a business) or a public network (e.g., 

the Internet), and a wireless network (e.g., sateUite network). ^n the computer 12. Among these resources are 

The network 22 can also be implemented as a telephone cryptography capabilities. The IC card stores public and 
network, or an mtcracUvc television network, or any other p^^ate key pairs and can hold related data such as public key 
form for hnking the computer 12 to an external source of certificates. The IC card also performs mdimentary crypto- 
informalion. graphic fiinctions, including encryption, decryption, signing. 

The IC card 14 is a portable card-like device with pro- authentication. The IC card may also contain resources in 
cessing capabilities, allowing it to be used for many different ^orm of electronic assets, which represent value. For 

purposes. In the illustrated implementations, IC card 14 is a instance, the IC card might store assets in the form of 
smart card. A "smart card*' is the approximate size of a electronic entertainment tickets, travel reservations, service 
standard credit card and has a built-in microcontroller contracts, medical prescriptions, government entitlement 
(MCU) 28 which enables the card to modify, or even create, provisions, electronic cash, public transportation tokens, and 
data in response to external stimuli. The microcontroller 28 35 so on. With such diverse resources, the IC card 14 is capable 
is a single wafer integrated circuit (IC) which is mounted on of supporting multiple applications in different environ- 
an otherwise plastic card. A smart card is physically con- ments. 

structed in accordance with the international standard ISO- Before this invention, the IC cards have generally sup- 
7816 which governs size and bendable limits of the plastic ported only a very limited set of applications, most corn- 
card, as well as size and location of the silicon integrated monly a single application, which were pre-programmed at 
circuit. An example smart card implementation is described time of manufacture. It has been tacitly assumed that the end 
in more detail below with reference to FIG. 3. In other user lacks the facilities to configure and manage the IC card, 
implementations, the IC card might be in the form factor of As a result, the user has needed multiple cards to support 
a PCMCIA card (i.e., PC card) or a floppy diskette, with one various applications. For instance, a user might have an 
or more processing chips configured thereon. Accordingly, 45 access card that he uses to enter his work place, a bank card 



might, however, be implemented in other forms with differ- 
ent appearances. For example, the computer 12 might be 
implemented as a PC-based point-of-sale machine or kiosk 
that is employed by merchants, or an automatic teller 
machine (ATM) used by banks, or a computerized vending 
machine, or an electronic ticket apparatus, or a set-top box. 
There are many different forms that the computer 12 might 
assume, with each possible computer implementation being 
capable of exchanging data with the IC card. 

Depending upon the computer configuration and its oper- 
ating environment, one or more software applications 
execute on the computer. A uscr*s home or work computer 
typically executes many different applications. Conversely, 
a computer implemented as a kiosk, ATM, or vending 
machine might only execute one specific application. The 
applications typically run on an operating system that is 
executing on the computer 12. The operating system is 
preferably a disk-based graphical operating system, such as 
Windows® 95, Windows® NT, or other Windows®- 
compatible systems, ahhough other operating systems can 
20 be employed, such as MS-DOS® or a customized operating 
system speciaUy designed for a particular environment. 

The multi-purpose IC card 14 contains various resources 
that might be used by, or in support of, an application 



as used in this disclosure, the term "IC card" means a 
portable, low energy, electronic device with processing 
capabilities and memory. Such devices typically lack their 
own user interface (i.e., a keypad or display), but can be 
constructed with some user interface capabilities. 

A card reader 26 is coupled to the computer 12. The card 
reader 26 interfaces with the IC card 14 (electronically, 
magneticaUy, RF, or otherwise) to transfer information to 
and from the IC card. In this implementation, the IC card 14 



50 



that he uses to access his bank account, a token card that 
allows him to ride public transportation, and so on. An 
aspect of this invention, however, is to provide both a 
multi-purpose IC card 14 which can be employed in many 
different environments as well as the tools which will allow 
the user to manage that card and its supported applications 
over time. The net result will be that the end user can do 
more while carrying fewer cards. 
The multi-purpose IC card 14 provides a safe means for 



is physically inserted into a slot in the card reader 26 (as 55 transporting the resources stored thereon. The I C card 14 can 



represented by the direction arrow). Interface pads on the 
card's MCU 28 make electrical contact with leads in the card 
reader, forming an electronic interface between the IC card 
14 and the computer 12. Fo flowing a transaction, the IC card 
is removed from the card reader 26 and transported with the 
user. In other implementations, the card reader 26 might be 
implemented to communicate with the IC card 28 in a 
wireless or remote fashion without the physical coupling. 

The computer 12 controls the information transfer 
between the card reader 26 and the IC card 14. The iUus- 
trated system represents a typical desktop computer that a 
user might use at home or work. The computer system 



be physically ported with the user from place to place. The 
die design and fabrication processes used to manufacture the 
microcontroUer IC yield a highly tamper-resistant card that 
is very difficult to reverse engineer and extract information. 
60 Thus, even if the card were lost or stolen, it is very difficult 
to obtain confidential information in the short time frame 
before the card is reported as lost and marked inactive. The 
IC card thus offers a secure storage and transportation 
mechanism for the cryptographic resources, and namely, the 
65 private keys. 

The computer system 10 includes a software appflcatioo 
interface which executes on the computer 12 to prevent 
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possible coven attacks from malicious software applications 
which attempt to gain unauthorized access to resources on 
the IC card. The application interface implements the appli- 
cation and provides services which facilitate access to the 
resources on the ICcard 14, without allowing the application 
itself to directly access the card-based resources. The appli- 
cation interface is implemented as a service layer for the 
operating system and is securely integrated with the oper- 
ating system through mutual authentication. During 
initialization, the apphcation interface and the operating 
system exchange certificates containing identifications (i.e., 
serial numbers or the like) which are signed by a trusted 
certifying authority (e.g., the manufacturer). The operating 
system and apphcation interface then authenticate each other 
using the certificates. One technique for authenticating the 
various components in a computer system is described in a 
co-pending U.S. patent application Scr. No. 08/531,567, 
now U.S. Pat No. 5,221,781 filed Sep. 13, 1995, entitled 
"Authentication System and Method for Smart Card Trans- 
actions," This application is hereby incorporated by refer- 
ence. 

The application interface is preferably an application 
program interface with a set of functional APIs that can be 
called by the application to support a particular fuinction- 
ahty requested by the apphcation. An example set of APIs 
are described below in more detail. 

HG. 2 shows an architecture of the computer system 10. 
It generally consists of three software layers and two hard- 
ware layers. At the lowest hardware layer, there is an 
electrical interface (direct or remote) between the IC card 14 
and the card reader 26. An I/O controller 30 is provided at 
a hardware interface layer to control the data transfer to and 
from the card reader. The I/O controller 30 is typically 
implemented as a control board resident in the computer 
CPU and connected to the CPU bussing structure. A soft- 
ware driver 32 defined by the operating system controls 
operations of the card reader 26 through the I/O controller 
30. 

The multiple applications, referenced generally as number 
34, run on the operating system at a high level, application 
layer. The API layer, referenced generally as number 36, 
resides between the application layer and the driver layer. 
The application interface 36 is a service layer which sup- 
ports three distinct types of services: (1) configuration 
services which permit a user to reconfigure the 10 card with 
those resources tailored to the user*s preferences; (2) secu- 
rity services which enable access to the cryptographic func- 
tionality on the IC card; and (3) resource management 
services which permit the user to manage the resources 
provided by the IC card. 

The API 36 includes a card management services module 
38 and a cryptographic services module 40. The card man- 
agement services module 38 implements administration 
functionality for the applications 34 for managing resources 
maintained on the IC card 14. When the apphcation requests 
that an administrative task be performed on the IC card 14, 
the card management services module 38 communicates 
with the IC card to perform the administrative task. As an 
example, the administrative tasks include initiaUzation of 
the IC card, cryptographic key generation, passcode 
configuration, management of cryptographic keys on the IC 
card, management of certificates on the IC card, and man- 
agement of assets on the I C card. The interface presented to 
the user by the card management services module is con- 
sistent and application independent for usability. An 
example set of API caUs is described below in more detail. 

The cryptographic services module 40 implements cryp- 
tographic fiinctionality for the apphcation 34 while using 
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cryptographic resources maintained on the IC card 14. When 
the application 34 requests a cryptographic function, the 
cryptographic services module 40 communicates with the IC 
card 14 and works cooperatively with the IC card 14 to 

5 perform the cryptographic function without exposing the 
cryptographic resources maintained on the IC card 14. As an 
example, the cryptographic services module 40 supports the 
following requests from the application: generating one or 
more cryptographic keys on the IC card, retrieving the 
pubhc component of a pubfic/private cryptographic key pair 
from the IC card, adding a certificate (or other data resource) 
to the IC card, retrieving a certificate firom the IC card, 
deleting a certificate from the IC card, generating a message 
digest based on an apphcation suppUed message, signing a 
message digest, encrypting data suppfied by the apphcation, 

15 decrypting data suppfied by the apphcation, verifying a 
signature supplied by the apphcation, encrypting an encryp- 
tion symmetric key for key exchange, decrypting a sym- 
metric key suppUed by the application. An example set of 
API calls is described below. 

20 In the illustrated implementation, the cryptographic ser- 
vices module 40 comprises a cryptographic apphcation 
program interface (CAPI) 42 which provides funclionafity lo 
the executing application 34 and one or more cryptographic 
service providers (CSF^) 44 which implement the crypto - 

25 graphic functionality presented by CAPI 42 to the applica- 
tion 34. The CAPI layer 42 is thin. Its principal task is to 
select an appropriate CSP and verify its authenticity. When 
the application 34 needs a sequence of cryptographic func- 
tions to be performed (e.g., encryption, decryption, signing), 

30 the apphcation invokes the CAPI 42 to acquire a context 
associated with the appropriate CSP. The CAPI 42 then 
loads the CSP and verifies its authenticity. Each CSP is 
digitally signed by a certifying authority using that authori- 
ty's private signing key. A corresponding public signing key 

35 of the certifying authority is embedded in the CAPI 42 so 
that the CAPI 42 can verify the authenticity of the CSP 44 
by validating the digital signature of the certifying authority, 
lliis verification prevents introduction of a foreign or impos- 
tor CSP 

40 The CAPI 42 also provides an insulating layer between 
the application and the CSP so that the apphcation never has 
direct access to the CSP, but can only call to the CSP through 
the CAPI. The CAPI 42 is preferably implemented in 
software, which is stored in memory of the computer 12 and 

45 executed on the CPU 16. 

The CSPs implement the cryptographic function afity 
requested by the application. In general, the CSPs perform 
encryption/decryption services, authentication, key 
exchange tasks, hashing routines, and digital signing. A 

50 different CSP can be configured to perform each of these 
functions, although a single CSP can be implemented to 
perform them all. Each CSP, or a dedicated CSP, can be 
configured lo communicate with the IC card 14. The CSPs 
44 are independent from, but dynamically accessible by, the 

55 CAPI 42 using conventional loading techniques. 

The CSP is preferably implemented in software as 
dynamic linked tibraries (DLLs). This implementation is 
advantageous because it can be easily invoked by the CAPI 
or by the apphcation through the CAPI. Furthermore, the 

60 cryptographic functions can be changed or updated simply 
by replacing one or more DLLs. With the CAPI layer in 
between, the CSP DLLs can be replaced without affecting 
how the application interacts with them. Additionally, by 
packaging the cryptographic services in DLLs, it will be 

65 possible to change the strengths of the services as regulatory 
considerations change without impacting the higher level 
apphcation. 
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A more detailed explanation of a cryptographic system non -confidential user information 74, such as medical data 

which employs the CAPI and CSP architecture is found in or driver's license information. This information is distrib- 

a co-pending U.S. patent appUcation Sen No. 08/496,801, uied freely by the IC card 14, without any special security 

now U.S. Pat. No. 5.689,565 filed Jun. 29, 1995, entitled protocol or the need for the user to enter a personal passcode. 

"Cryptography System and Method for Providing Crypto- 5 The private storage 72 maintains information of which the 

graphic Services for a Computer Application." This appli- use^ ^sbes to control distribution. The processor 50 only 

cation was filed under the names of Terrenoe R. Spies, retrieves information from the private storage 72 upon 

Jeffrey F Spelman, and Daniel R. Simon and is assigned to authorization by the user as indicated when the user enters 

Microsoft Corporation, This apphcation is mcorporated ^ p^^^^^^ passcode. This passcode is entered into the 

Ia ^ ^ , 10 computer, passed through the card reader to the card 1/0 

The IC card 14 stores and manages the cryptographic keys processor 50. Tlie processor 50 compares 

and associated data resources used by the CSP 44 m per- {^^ ^^^^^^ ^ ^ ^^^^ ^^^^^ ^ ^^PROM 

formmg the cryptographic ftinction. ^e IC card 14 can also ^^^^ to contents stored on the private 

the CSP "^"^ cryptographic functions m support of ^^^^^^^ ^^.^ ^^^^^^ ^^^^ p^^^ ^^^^^ 

^ An advantage of the FIG. 2 architecture is that the API 36 P"^^»^ ^^^'^^f^!^ EEPROM 56 stores two asym- 

and IC card 14 offer a uniform platform which supports ^^^'l P^.l^^ public and private cryptography keys 

many different applications. Independent vendors can ^^1^^ ^^,7^ pair and the exchange pair. One or more 

develop different applications which employ the services certificates 78 arc also stored in the pnvate storage 78. 

provided by the API 36. without needing io write hardware certificates might contain a card ID, or user ID, public keys, 

specific code for accessing the IC card. Additionally, the '° ^"^^a signature of a certifying authority. One certificate 

layered architecture and inherent tamper-resistance of the IC ^ number of different applications, or 

card promotes security of the private keys. alternatively, for only a specific correspondmg application. 

RG. 3 shows the IC card 14 implemented as a smart card, ^^'^ ^^^signed to avoid exposing the private 

and particularly, shows the microconlroUer 28 of the IC card ,5 k^VS- The encryption keys are never directly accessible and 

14. The MCU 28 has a CPU or processor 50, a volatile asymmetric private sigmng and exchange keys are not 

rewritable RAM (Random Access Memory) 52, a ROM permitted to leave the IC card under any circumstances. In 

(Read Only Memory) 54, and an persistent reader/write manner, the IC card prevents a foreign application from 

memory such as EEPROM (Electrically Erasable Program- ^^^r inadvertently or intentionally mishandlmg the keys m a 

mable ROM) 56. A multi-bit bus 58 connects the compo- 30 ^^^^ ''^''^ ^ intercepted and compro- 

nents. Interface contacts or ports 60 are shown as an naised. 

example coupling for an electronic interface. These include When an application 34 requests cryptographic functions, 

clock, reset, power, data I/O, and ground. Data is transfer is the IC card 14 works in cooperation with the CSP 44 to 

controlled by CPU 50 through serial I/O port 60 and provide cryptographic functionality. The CSP performs most 

conductor 62. 35 of encryption and decryption processes which require 

This invention includes implementation of system greater computational resources. With present technology, 
software, held in mask ROM, for IC cards such as those IC cards in general cannot adequately perform full 
described above. This system software is designed to be encryption/decryption of large size documents/messages 
tightly coupled with the cryptographic services and card due to I/O and processing limitations of the smaU micro- 
administrative modules previously described to create a 40 controller. However, the IC card can provide signatures and 
complete multi -apphcation system. The IC card is config- verification functions, and is capable of encrypting or 
ured with various cryptographic functionality to support the decrypting smaU messages. As technology continues to 
cryptographic services module 40 in the API 36. In the evolve, it is expected that IC cards will have powerfull and 
illustrated embodiment, the IC card 14 is configured with fast processors that can satisfactorily encrypt messages of 
cryptography acceleration circuitry 64, shown integrated 45 ^^^^ ^^^^^ °^ ^^^^^^ 
with the CPU 50, which streamlines cryptography compu- environment without noticeable or imtatmg delay, 
tations to improve speed. The cryptography accelerator 64 With continuing reference to FIG. 3, electronic assets 80 
can alternatively be implemented independently of the CPU. are also stored in the private segment of the EEPROM 56. 
The ROM 54 stores a cryptographic program 66 which These electronic assets represent value, and might include 
executes on the CPU 50 in conjunction with the cryptogra- 50 tickets, tokens, e-cash, service contracts, medical 
phy accelerator 64 to perform certain cryptographic prescriptions, reservations, government entitlements, or a 
functions, including encryption, decryption, signing, and pointer to a source of value. Non-cryptographic programs 82 
verification. that the user might wish to load onto the IC card are kept in 

The cryptographic program 66 can be implemented as one the EEPROM 56. These programs can be complimentary 

or more cryptographic service providers (CSPs) to perform 55 routines that assist the applications running on the computer 

these cryptographic functions. As an example, the crypto- to organize or manipulate data and assets on the card, 

graphic program 66 can encrypt and decrypt short messages Unlike prior art IC cards and readers which are factory 

using asymmetric key cryptography, such as RSA, and configured and offer limited, if any, customization by the 

symmetric key cryptography, such as DES (Data Encryption user, the computer system 10 permits the user to extensively 

Standard). The cryptographic program 66 might also be 60 configure the IC card 14 according to his/her preferences 

capable of generating and destroying cryptographic keys, after the card has been issued. As shown in FIG. 2, the 

such as symmetric keys used in the bulk encryption/ computer system 10 has a card manager user interface (Ul) 

decryption of a message. The symmetric keys are typically 84 executing on the computer CPU at the application layer 

"sessional," meaning they are generated for each transaction The card manager UI 84 presents a uniform set of graphical 

and then subsequently destroyed. 65 dialog screens which enable the user to conveniently and 

The EEPROM 56 is partitioned into a public storage 70 easily manage the card resources (including cryptographic 

and a private storage 72. The public storage 70 contains resources, assets, etc.) from the computer. 
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FIGS. 4 and 5 show aa example of a card manager 
graphical pop-up box 90 having different graphical dialog 
screens that arc generated by the card manager Ul and 
displayed to the user. FIG. 4 shows an example passoode 
dialog screen 92 which allows the user to change his/her 
passcode. To reach this screen, the user inserts the IC card 
into the card reader and enters the appropriate passcode to 
verify the user to the I C card. Thereafter, the user selects the 
card manager dialog box 90 and pulls up the passcode screen 
92 to change the passcode. The user enters the old passcode, 
then the new one, and confirms the change. A card icon 94 
along the bottom enables the user to select the appropriate IC 
card, in the event the user has more than one IC card that 
requires management. 

When the user changes the passcode, the new passcode is 
passed to the card management services module 38 of API 
36. This services module accesses the card and overwrites 
the old passcode stored in the EEPROM 56 of the IC card 
with the new passcode. 

FIG. 5 shows an example resource management graphical 
screen 96 which is also part of the card manager pop-up box 
90. The resource screen 96 provides a convenient interface 
that allows the user to manage the resources maintained on 
the card. The resource screen 96 presents a list 98 of 
resources that are presently stored on the user's IC card and 
a resource list 100 of available resources that can be added 
to the card. The icons represent various resources, such as 
parental control feamres 102, financial account access 104, 
entertainment-related assets 106, medical information 108, 
travel reservations 110, and telephone assets 112. 

The user manipulates the icons to add assets to, or remove 
assets from, the IC card. This can be done using a conven- 
tional drag-and-drop protocol where the user clicks on the 
desired icon using a mouse or other pointing device, and 
drags the icon to the appropriate location. For instance, the 
user can drag the travel icon 110 from the resource list 100 
to the card list 98 to add this resource to the card. In the 
illustrated example, a travel-relate asset (i.e., ticket 
reservations) has been added to the user's card. The IC card 
is thus equipped with travel accommodations and the user 
can port the IC card to the airport to download this travel 
asset when checking in for the flight. Other task-oriented 
input protocols, in addition to the drag-and-drop protocol, 
can be used to manage the resources on the IC card. 

When the user manipulates the resources on the IC card, 
the card management services module 38 perfonns the actual 
card maintenance. For instance, to add a ticket-related asset, 
the card management services module 38 downloads the 
new "ticket" (i.e., application defined electronic representa- 
tion of the ticket) to the IC card which is stored in the 
EEPROM. As another example, to add new cryptographic 
resources, the card management service module 38 might 
reconfigure the processing capabilities of the IC card by 
updating or changing a stored programs kept in memory the 
IC card read/write memory. 

The passcode screen 92 (FIG. 4) and the resource man- 
agement screen 96 (FIG. 5) are shown for example purposes. 
Tliere can be many other types of screens. For example, a 
certificate screen 114 permits the user to manage various 
certificates which have been issued for the public keys 
stored on the IC card and associated with various applica- 
tions such as authentication, electronic payment, electronic 
travel, etc. An initialization screen 116 enables the user to 
initialize the IC card to an initial state. After initialization, 
the user can configure the IC card to his/her preferences. 

With the use of the card manager UI, the multi-purpose IC 
card can be configured and managed by the user. Unlike 
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prior art systems, which were proprietary and closed to user 
configuration, the computer system 10 promotes user con- 
trolled management of the card through the API 36 and card 
manager UI 84. 

5 FIG. 6 shows an example ilhistration of how the IC card 
14 is used for many different applications, while securely 
storing the resources on the card. In this example 
illustration, IC card 14 is configured with the user's medical 
information, financial data, work access account, tokens for 

10 beverage and snack vending machines, and various online 
service accounts including an electronic shopping account. 

The user first inserts the IC card 14 into his/her home 
computer 120 for initialization and configuration using the 
card manager UI, Using the card manager Ul, the user sets 
the IC card to an initial state in which the memory is cleared. 
The user then establishes one or more passcodes, which are 
stored on the IC card. Next, the user configures the IC card 
with certain resources to tailor the card to his/her prefer- 
ences. 

20 

As part of the configuration, the cryptographic services 
module 40 of API 36 instructs the IC card processor 50 to 
generate a unique signing pair of public/private keys and a 
unique exchange pair of public/private keys. The user con- 

2^ nects to a certifying authority via a public network 122 (e.g., 
the Internet) and sends identification information along with 
the public keys to the certifying authority. The certifying 
authority returns a certificate containing the identification 
information and public keys, and a signature of the certify- 
ing authority. The certificate is stored on the I C card 14. 

Now suppose the user transports the IC card 14 to work. 
The user inserts the IC card 14 into bis/her workstation 
computer 124 which is attached to the company network 126 
(e.g., Ethernet LAN). The user enters the passcode to 

35 activate the IC card. The security application running on the 
workstation computer (or elsewhere on the network) then 
communicates with the IC card to verify the IC card (and 
hence the user) for access to the services on the network. The 
IC card might also wish to verify the authenticity of the 

40 security application. This can be done by exchanging 
authentication information between the security application 
and the IC card. 

After work, the user ports the IC card 14 to a banking 
ATM 128 to withdraw cash. The ATM is an online computer 

45 attached to a proprietary bank network 130. The user inserts 
the IC card 14 into a card reader and enters his/her passcode 
(which could be different than the passcode used for work or 
home) to authenticate the user to the I C card. Next, the IC 
card and banking application running on the ATM exchange 

50 authentication information. The banking application then 
conducts a financial transaction through the API to the IC 
card. In the cash withdrawal operation, the IC card signs a 
request for cash using a private signing key on the IC card. 
The request is transferred to the ATM banking application 

55 through the API without exposing the signing key. The ATM 
then transfers electronic cash to the IC card 14 and debits the 
user's account. The electronic cash is stored in the private 
storage of the programmable memory of the IC card 14. 
The user is free to spend the electronic cash on various 

60 goods and services, such as tokens for public transportation, 
food at a grocery store, and so on. As a further example, 
suppose the user decides to purchase a beverage from a 
vending machine 132. The user transports the same IC card 
14 to the vending machine 132 and inserts it into a com- 

65 patible card reader. The vending machine is an example of 
an ofQine computer, one that is not attached to a back end 
network. When the user selects the beverage, a vending 
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machine applicaiion runoing on the vending machine compares the passoode with one stored in memory for 

requests through the API that the monetary equivalent of the purposes of verification (step 152 in FIG. 7). If the entered 

cost of a beverage be withdrawn from the IC card 14. To and stored passcodes match, the user is presumed authentic 

access the private storage, the user might be requested to and the IC card is prepared for interaction with a selected 
enter a passcode which is verified to the IC card. On the 5 appUcaiion. 

other hand, for such low cost items, there may be no need to Certificate Exchange 

verify the user via the passcode, or any other security Suppose the user wishes to purchase a product from a 

protocol. The IC card 14 exports assets sufficient to pay for merchant over a public data network, such as the Internet, 

the beverage to the vending machine application, which then The user begins a commerce application 34 on his/her 
releases the beverage. lO computer which enables the user to browse and purchase 

Now suppose on the way home, the user is injured and goods from the merchant (step 154). For this example, 

requires evaluation at a hospital 134. The IC card 14 can be assume that the IC card 14 and the commerce application 34 

accessed at the hospital to download the user's medical have already mutually authenticated each other through the 

information from the public storage of the IC card's exchange of certificates. 

EEPROM. This can be done without requiring the user's 15 When the user is ready to place an order, the user and 

passcode in the event the user is i unable to function due to merchant computers will first exchange certificates. These 

the injury validated and the public keys contained therein are used 

After being released from the hospital, the user returns '° •^'^V authealicalion protocol and to 

home. On doctor's orders, the needs to purchase securely exchange symmetric key wformauon if required to 

... |. , • * • \u ™ 20 establish a secure communication channel, 

medical supplies to assist in the recovery. The user decides r^Am.. . ■ jiio 

. . , 1 f u t iu ur The API card management services module 38 executing 

to buy the medical supphes from a merchant over the pubhc . . -.*»uf*-^ ^ 

™ • * 4U ir- ^ ■ ♦ *u u ™„ on the user s home computer instructs the I C card processor 

ne work. The user inserts the IC card 14 into the home _^ . . , ^^-^ , n 

. -i-in J • * iu ur f, J m 50 to retneve the particular certificate for this commerce 

computer 120 and gains access to the pubhc network 122. . , • .t_ i.-. ^ rmnr^xM ma u ^ i 

- . .. u i A ' -r i « apphcation (may be in the IC card EEPROM 54, a hard disk, 

The user finds a medical supplies merchant and initiates an ^ i_ .i_ - c . \ ^ 

. . . . f- 4- .u , 25 etc. fas there can be more than one certificate), and exports 

order using a shoppmg application executmg on the user s . ^ , . i^ / , -n. 

& & I'F \ the certificate to the apphcation 34 (step 156). The user s 

home computer, or remotely from the merchant over the , . . ^> ^ . ' , ^ 

1 A «u *• • <• ™ o ^^^knr.™^ K^hw^^r, computcr aud thc mcrchant s computing UHit theH exchaugc 

ne work. Authentication information is exchanged between . ^ ^ . r.^ 

r 1 c *• the certificates over the pubhc network (step 158). 

the IC card and shopping apphcaUon for mutual verification. • . r.u u .» . fu 

1 J u- u • *A A Upon receipt of the merchant s certificate, the commerce 

The user then places an order, which is encrypted and .f . u .u u ^^w fi,,Ito ti„«,.^t, tu^ 
, J ' . , 1 * 4U ™ 30 apphcation submits the merchant s certificate through the 

signed, and sends the order over the network to the mer- ^ , ^ u Amiic* .u mZ^^AtA 

J * - t *• ™ J card management and cryplographyAPI 36 to the IC card 14 

chant. The encryption and signing functions are performed . iz:n\ m. a cn • «u 

*• 1 u ♦ iu I/- AtA ^ tk^ ADi ^™^.t„„ (step 160). The card processor 50 examines the signature on 

cooperatively between the IC card 14 and the API executing p ♦u » •« k i « »v.« .«w-p,^ «« 

/, , u-i • A the certificate to verify that it belongs to the certifying 

on the user s home computer, while usmg the signing and . , . ^ if,u t wli.^T 

u 1 1 * fu ir^ A ' .^iTZ^Z. authority in this context (step 162). If the certificate IS valid, 

exchange keys kept on the IC card. The private keys are . ^ ^.n ■ c /• u u i a a*u 
J * u . 1- -ru V, * 35 the merchant identifying mformation can be checked and the 

never exposed to the merchant apphcation. The merchant ... . , ; ^ ^, . ^ «.,^u.„t ,.c;r»rr ^ 

, , c .1. . ■ * It: ^'A pubhc keys used to authenticate the merchant usmg a 

decrypts the order and venfies the user s signature. If vahd, . n . i 

the merchant ships the medical supphes and bills the user. chaUengerespon^ protocol. 

'^'^ Encryption and Signing 

The FIG. 6 example demonstrates that the same IC card commerce application generates an order, which is 

can be used in many different environments. Furthermore. approved by the user (step 164 in FIG. 8). The order is 

the card can be easily configured to add additional capabili- encrypted so that it may be securely transmitted over the 

ties as they come along. The IC card is a secure means for ^^^^ insecure public network. To perform the 

transporting the user's certificates, private/pubUc key pairs, encryption, the commerce application 34 supplies a plaintext 

assets, and other information. Due to the sophisticated die ^^^^^ ^j^^ to be encrypted and signed (step 166). 

processing techniques, the microcontroller die on the IC The CAPI 42 selects the one or more CSPs 44 to perform the 

card is very difScult to reverse engineer, making it a very encryption and signing (step 168 in FIG. 8). This entails 

secure vehicle. The private keys are well protected. loading the appropriate DLL, and performing a series of 

Moreover, the private keys never leave the IC card; rather, ^^^^^ ^ ^^jj^ ^^^^^ encryption and to 

the complimentary API running on the computer facilitates digitally sign the result. For purposes of continuing 

data communication with the IC card to perform the cryp- discussion, the operation will be described as if the CSP 44 

tographic fuinctions without ever exposmg the pnvate keys ^^^^^^ performing all of the requested cryptography 

to the API or apphcation. fiinctions. 

To further demonstrate how the IC card and computer- Communication is established between the CAPI 42 and 

based API work together to protect the user's keys, the cSP 44 (step 170 in FIG. 8). The CAPI 42 verifies the 
following discussion provides a detailed example of an 55 authenticity of the CSP 44 by validating the binding authori- 

electronic purchase transaction between a user or purchaser ty*s digital signature attached to the CSP 44 using the 

and a merchant. This example is described in reference to binding authority's public signature key embedded in the 

FIGS. 1-3 and to the flow diagram of FIGS. 7-12. where CAPI 42 (step 172). 

FIGS. 7-10 represent steps taken at the user's premises and Once the CSP is authenticated, the CAPI 42 passes the 
FIGS. 11-12 represent steps taken at the merchant's pre- go plaintext order to the CSP 44 for encryption (step 174 in 

raises. FIG. 8). The CSP 44 uses a hash function to translate the 

To begin the process, with reference to the flow diagram plaintext order into a cryptographic digest or hash (step 176 

of FIGS. 7-10, the user inserts the IC card 14 into card in FIG. 9). A hash function is a mathematical function that 

reader 26 of computer 12. This computer might be, for converts an input data stream into a fixed-size, often smaller, 
example, the user's home computer or a set-top box. The 65 output data stream that is representative of the input data 

user enters a personal passcode which is passed to the IC stream. The CSP passes the digest to the IC card (step 178). 

card 14 for authentication (step 150 in FIG. 7). The IC card The card processor 50 digitally signs the cryptographic 
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digest (bash) by encrypting the digest using the user's 
private signing key of the asymmetric key pair (step 180 in 
FIG. 9), as foUows: 

^KsiM^i^r (Order Hafib)-Signature 

The signing operation employs an asymmetric key algo- 
rithm which involves two separate keys, one key to encrypt 
the hash (i.e., sign) and one key to decrypt the hash (i.e., 
unsign). The keys are based upon a mathematical relation- 
ship in which one key cannot be calculated (at least in any 
reasonable amount of time) from the other key. The private 
signing key is kept by the user on the IC card, while the 
public signing key is distributed in the certificate to the 
merchant. An example asymmetric cipher is the well-known 
RSA cryptographic algorithm named for the creators Rivest, 
Shamir, and Adleman. 

The digital signature (i.e., signed hash) is returned to the 
CSP 44 (step 182) and attached to the order. The CSP 44 
generates a symmetric bulk data encryption key and 
encrypts the order and digital signature using the new 
symmetric encryption key (step 184 in FIG. 9). In a sym- 
metric cipher, the encryption key can be calculated from the 
decryption key, and vice versa. In many cases, the encryp- 
tion key and the decryption key are the same. The symmetric 
key must be known to both the sender and receiver, but 
otherwise kept secret. Once the symmetric key is divulged, 
any party can encrypt or decrypt messages. Example sym- 
metric ciphers are a DES (Data Encryption Standard) 
encryption algorithm or an RC4 algorithm. The encryption 
of the order and signature is represented as follows: 

^tUym (order+signature)-ordei.ciic 

It is noted that the IC card 14 might perform the key 
generation function of generating the symmeUic session key 
and exporting them to the CSP 44. Additionally, when 
processing capabilities of the IC card improve, the IC card 
itself might perform the bulk data encryption. After the order 
is encrypted, the CSP 44 encrypts the symmetric encryption 
key using the key exchange public key of the merchant that 
was originally received in the merchant's certificate (step 
186), as follows: 

The asymmetric public/private exchange keys ensure that 
only the holder of the private key can decrypt a message that 
is encrypted with the corresponding public key. 

The CSP 44 returns the signed and encrypted order to the 
CAPI 42, which passes it onto the application 34 (step 188 
in FIG. 10), The symmetric key is exported from the CSP in 
encrypted formal, not in plaintext formal. Furthermore, the 
asymmetric private signing and exchange keys remain per- 
manently protected on the IC card and are not exposed to 
either the CSP or application. The order is then transmitted 
from the user's computer over the network to the merchant's 
computer (step 190). 
Decryption and Authentication 

With reference to FIGS. 11-12, the commerce application 
running at the merchant's computer receives the signed 
encrypted order and passes the package to its own API 
cryptography services module 40 (step 192 in FIG. 11). The 
encrypted order is supplied to the CAPI 42 for purposes of 
being decrypted and verified. The CAPI 42 selects the 
appropriate CSP or CSPs 44 to perform the decryption and 
verification (step 194). The appropriate CSP DLL is loaded 
and the application performs a series of calls to the DLL 
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through the CAPI. Communication is established between 
the CAPI 42 and selected CSP 44 (step 196), and the CAPI 
42 verifies the authenticity of the CSP 44 (step 198). Once 
the CSP is authenticated, the CAPI 42 passes the encrypted 
5 order to the CSP 44 for decryption (step 200). The CSP 44 
decrypts the symmetric encryption key using the merchant's 
private key exchange key maintained on the merchant's IC 
card, or elsewhere (step 202 in FIG. 11), as follows: 

The recovered symmetric key is used to decrypt the order 
and user's digital signature to provide the plaintext order and 
the signed cryptographic digest (hash) (step 204 in FIG. 11), 
as follows: 

15 

Dfcy^ (ordcr.ciic)=order+5ignatuie 

At this point, the CSP passes the cryptographic digest 
(hash) to the merchant's IC card (step 206 in FIG. 12). The 
merchant's IC card verifies the signature by decrypting the 
hash using the user's public signing key which was received 
in the user's certificate (step 208). If the decryption yields a 
result that compares bit-for-bit with an independently, 
locally computed hash of the entire message (computed by 
the CSP and passed into the IC card), the merchant is assured 
that the packet came from the user and was not subsequently 
altered. This decryption and verification of the hash can 
alternatively be performed by the CSP if the merchant does 
not employ IC cards. If valid, the plaintext order is returned 
from the CSP 44 to the CAPI 42 and then to the commerce 
apphcation 34 (step 210). After the process is completed, the 
CSP destroys the symmetric encryption key that was 
employed for that session. 

In compliance with the statute, the invention has been 
described in language more or less specific as to structure 
and method features. It is to be understood, however, that the 
invention is not limited to the specific features described, 
since the means herein disclosed comprise exemplary forms 
of putting the invention into effect. The invention is, 
therefore, claimed in any of its forms or modifications within 
the proper scope of the appended claims appropriately 
interpreted in accordance with the doctrine of equivalents 
and other applicable judicial doctrines. 

We claim: 

1. A system for supporting at least one computer- 
implemented application to access and manage a multi- 
purpose integrated circuit (IC) card, the system comprising: 

a multi-purpose integrated circuit (IC) card having a 
plurality of resources for different uses; 
5Q a card reader which interfaces with the IC card to transfer 
information to and from the IC card; 
a computers coupled to the card reader, to implement at 
least one application to enable a user to access and 
manage select resources of the plurality of resources of 
55 the IC card; and 

an application -independent application interface execut- 
ing on the computer to implement services utilized by 
the computer-implemented application to facilitate user 
access to certain of the plurality of resources provided 
60 by the IC card. 

2. A system as recited in claim 1, wherein the application- 
independent application interface supports configuration 
services which permit a user to reconfigure the IC card. 

3. A system as recited in claim 1, wherein the application- 
65 independent application interface supports resource man- 
agement services which permit a user to manage the 
resources provided by the IC card. 
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4. A system as recited in claim 1, further comprising: 
an operating system executing on the computer, the 

application being run on the operating system; and 
the application-independent application interface is 
implemented as a service layer for the operating system 
and is securely integrated with the operating system. 

5. A system as recited in claim 1, wherein the IC card is 
a smart card. 

6. A system as recited in claim 1, wherein: 

the IC card has a memory to store at least one asset 
indicative of value; and 

the application-independent application interface is con- 
figured to retrieve the asset from the IC card for use by 
the application. 

7. A system as recited in claim 1, wherein the IC card 
comprises: 

a memory to store at least one cryptographic key; and 
a processor configured to perform a cryptographic func- 
tion using the cryptographic key stored in the memory, 

8. A sy^em as recited in claim 1, wherein the IC card 
comprises: 

a memory to store at least one certificate; and 
a processor configured to supply the certificate to the 
application-independent application interface. 

9. A system as recited in claim 1, wherein: 

the IC card has a memory to store at least one crypto- 
graphic key and a processor to provide cryptographic 
functionality using the cryptographic key; 

the application requests a cryptographic function involv- 
ing use of the cryptographic key stored on the IC card; 
and 

the application-independent application interface com- 
prises: 

a cryptographic application program interface (CAPI) 
to interface with the application and handle the 
application's request for the cryptographic function; 
and 

a cryptography service provider (CSP) independent 
from, but dynamically accessible by, the CAPI, the 
CSP providing the cryptographic function requested 
by the application, the CSP managing access to the 
IC card for use of the cryptographic key in support 
of the cryptographic function while protecting the 
cryptographic key stored on the IC card to prevent 
exposure of the cryptographic key to the CAPI and 
the application. 

10. A system as recited in claim 9, wherein the processor 
of the IC card is configured to perform a cryptographic 
function selected from a group of cryptographic functions 
comprising (1) encryption using the cryptographic key, (2) 
decryption using the cryptographic key, (3) digital signing 
using the cryptographic key, (4) verifying authentication of 
a digital signature using the cryptographic key, (5) genera- 
tion of the cryptographic key, and (6) destruction of the 
cryptographic key. 

11. A system as recited in claim 1, wherein the 
application-independent application interface is configured 
to support at least one request made by the application for a 
particular resource provided by the IC card, said at least one 
request being selected from a group of requests comprising 
(1) initializing the IC card to an initial state, (2) retrieving 
characteristics of the IC card, (3) retrieving an identification 
of the IC card, (4) logging into the IC card, (5) logging out 
of the IC card, and (6) changing a passcode for access to the 
IC card. 
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12. A system as recited in claim 1, wherein the 
application-independent application interface is configured 
to support at least one request made by the application for a 
particular resource provided by the IC card, said at least one 

5 request being selected fix>m a group of requests comprising 
(1) generating a cryptographic key for the IC card, (2) 
retrieving a public cryptographic key from the IC card, (3) 
adding a certificate or other data resource to the IC card, (4) 
retrieving a certificate or other data resource from the IC 

10 card, and (5) deleting a certificate from the IC card. 

13. A system as recited in claim 1, wherein the 
application-independent application interface is configured 
to support at least one request made by the apphcation for a 
particular resource provided by the IC card, said al least one 

15 request being selected from a group of requests comprising 
(1) signing data supplied by the application, (2) encrypting 
data supplied by the application, (3) decrypting data sup- 
plied by the application, and (4) verifying a signature 
supplied by the application. 
20 14. A system as recited in claim 1, wherein: 
the application requests digital signing of data; 
the application-independent application interface hashes 
the data to produce a hash and passes the hash to the IC 
card; and 

the IC card digitally signs the hash using a cryptographic 
signing key and returns the signed hash to the 
application-independent application interface without 
exposing the cryptographic signing key. 

15. A system as recited in claim 1, wherein: 
the application requests verification of a digital signature; 
the application-independent application interface passes 

the digital signature to the IC card; and 
the IC card verifies the digital signature using a crypto - 
35 graphic key and informs the application-independent 
application interface as to whether the digital signature 
is authentic, 

16. A system as recited in claim 1, wherein: 
the application requests encryption of data; 

the application interface passes at least a portion of the 

data to the IC card; and 
the IC card encrypts the data passed from the application 
interface using an encryption key and returns the 
encrypted data to the application interface, 

17. A system as recited in claim 1, wherein: 
the application requests decryption of encrypted data; 
the application interface passes the encrypted data to the 

IC card; and 

the I C card decrypts the encrypted data using a decryption 
key and returns decrypted data to the application inter- 
face. 

18. A computer-implemented application program inter- 
face to interface an application executing on a computer 

55 operating system with a program executing on an integrated 
circuit (IC) card, the IC card being coupled to communicate 
with a computer on which the operating system is running, 
the application program interface comprising: 
a cryptographic services module which implements cryp- 
60 tographic functionality for the application, the crypto- 
graphic services module using cryptographic resources 
maintained on the IC card so that when the application 
requests a cryptographic function, the cryptographic 
services module communicates with the IC card to have 
65 the IC card support the cryptographic function without 
exposing the cryptographic resources maintained 
thereon; and 
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a card management services module which implements 
administration functionality for the application for 
managing resources maintained on the IC card so that 
when the application requests that an administrative 
task be performed on the IC card, the card management 5 
services module communicates with the IC card to 
perform the administrative task requested by the appli- 
cation. 

19. A computer-implemented application program inter- 
face as recited in claim 18, wherein the cryptographic 
function is selected from a group comprising encryption, 
decryption, digital signing, and verification. 

20. A computer-implemented application program inter- 
face as recited in claim 18, wherein the administrative task 
is selected from a group comprising initialization of the IC 
card, cryptographic key generation, passcode configuration, 
management of cryptographic keys on the IC card, manage- 
ment of certificates on the IC card, and management of 
assets on the IC card. 

21. A computer-implemented application program inter- 
face as recited in claim 18, wherein the cryptographic 
services module comprises: 

a cryptographic application program interface (CAPI) to 
interface with the application and handle the applica- 
tion's request for the cryptographic function; and 25 

a cryptography service provider (CSP) independent from, 
but dynamically accessible by, the CAPI, the CSP 
performing the cryptographic function requested by the 
application by accessing the IC card for support of the 
cryptographic function while protecting the crypto- 30 
graphic resources on the IC card to prevent exposure of 
the cryptographic resources to the CAPI and the appli- 
cation. 

22. A computer-implemented application program inter- 
face as recited in claim 18, wherein at least one of the service 35 
modules is configured to support at least one request made 
by the application which is selected from a group of requests 
comprising (1) initializing the IC card to an initial state, (2) 
retrieving characteristics of the IC card, (3) retrieving an 
identification of the IC card, (4) logging into the IC card, (5) 40 
logging out of the IC card, and (6) changing a passcode for 
access to the IC card. 

23. A computer-implemented application program inter- 
face as recited in claim 18, wherein at least one of the service 
modules is configured to support at least one request made 45 
by the application which is selected from a group of requests 
comprising (1) generating a cryptographic key for the IC 
card, (2) retrieving a public cryptographic key from the IC 
card, (3) adding a certificate or other data resource to the IC 
card, (4) retrieving a certificate or other data resource from 50 
the IC card, and (5) deleting a certificate from the IC card. 

24. A computer-implemented application program inter- 
face as recited in claim 18, wherein at least one of the service 
modules is configured to support at least one request made 
by the application which is selected from a group of requests 55 
comprising (1) signing data supplied by the application, (2) 
encrypting data supplied by the application, (3) decrypting 
data supphed by the application, and (4) verifying a signa- 
ture supplied by the application. 

25. A computer readable memory comprising a computer- 
implemented appUcation program interface as recited in 
claim 18. 

26. A computer to configure and manage a plurality of 
resources of an integrated circuit (IC) card, the computer 
comprising: 55 

a processor; 
a display; and 
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a card manager user interface (UI) executing on the 
processor, the card manager UI presenting at least one 
graphical dialog screen on the display which enables a 
user to reconfigure the IC card and to manage the 
resources on the IC card. 

27. A computer as recited in claim 26, wherein the card 
manager UI has icons representing resources on the IC card. 

28. A computer as recited in claim 27, wherein the card 
manager UI enables a user to add and delete resources by 
manipulating the icons presented on the graphical dialog 
screen. 

29. A computer as recited in claim 26, wherein: 

the card manager UI presents a resource list of available 
resources that can be placed on the IC card; and 

the card manager UI enables the user to add resources 
from the resource list to the IC card and to remove 
resources from the IC card to the resource list. 

30. A configuration system enabling a user to configure an 
integrated circuit (I C) card after manufacture of the IC card, 
the IC card having a processor and programmable memory, 
the configuration system comprising: 

a computer having a card reader to interface with the IC 
card; and 

a card management application interface executing on the 
computer to enable the user to access the IC card and 
add, delete and otherwise configure the resources of the 
IC card stored within the programmable memory with 
data selected by a user. 

31. A configuration system as recited in claim 30, wherein 
the card management application interface permits a user to 
manage resources on the IC card. 

32. A configuration system as recited in claim 30, fuirther 
comprising a graphical user interface executing on the 
computer to present graphical representations of resources 
that are available on the IC card. 

33; An integrated circuit (IC) card comprising: 
a processor; 

a data I/O port controlled by the processor to receive and 
output data; 

a data memory coupled to the processor, the data memory 
being partitioned into a public storage and a private 
storage; 

the processor being configured to access the private 
storage of the data memory only following receipt and 
verification of an externally supplied passcode from the 
data I/O port; and 

the processor being configured to access the public stor- 
age and output contents stored in the public storage to 
the data I/O port without requiring receipt and verifi- 
cation of the passcode. 

34. An integrated circuit (IC) card as recited in claim 33, 
wherein the private storage stores at least one cryptographic 
key, 

35. An integrated circuit (IC) card as recited in claim 33, 
wherein the private storage stores at least one public key 
certificate. 

36. An integrated circuit (IQ card as recited in claim 33, 
wherein the private storage includes a permanent memory 
location to permanently store at least one private crypto- 
graphic key. 

37. An integrated circuit (IC) card as recited in claim 33, 
wherein the private storage stores electronic assets indica- 
tive of commercial value. 

38. An integrated circuit (IC) card as recited in claim 33, 
wherein the IC card is uniquely assigned to a user, and the 
pubHc storage stores non -confidential information pertain- 
ing to the user. 
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39. A method lo provide cryptographic function support to 
a requesting application, the method comprising the follow- 
ing steps: 

storing at least one cryptographic key on a portable 
integrated circuit (IC) card; 5 

supplying a request for a cryptographic Unction from the 
application to an application-independent application 
interface; 

establishing data communication between the appUcation- 
independent application interface and the IC card; and 

performing the cryptographic function requested by the 
application cooperatively between the application- 
independent application interface and the IC card using 
the cryptographic key stored on the I C card and without 15 
exposing the cryptographic key from the IC card. 

40. A method as recited in claim 39, wherein the per- 
forming step comprises the cryptographic function is 
selected from a group comprising encryption, decryption, 
digital signing, and verification. 20 

41. A method as recited in claim 39, wherein the per- 
forming step comprises digitally signing data according to 
the following steps: 

hashing the data at the aplication-independent application 
interface to produce a bash; 25 

passing the hash from the application-independent appli- 
cation interface to the IC card; 

digitally signing the hash using a cryptographic signing 
key; and 

passing the signed hash from the IC card back to the 
application independent application interface without 
exposing the cryptographic signing key. 

42. A method as recited in claim 39, wherein the per- 
forming step comprises verifying a digital signature accord- 
ing to the following steps: 

passing the digital signature form the application- 
independent application interface to the IC card; 

verifying the digital signature using the cryptographic 
key; and 40 

infonming the application-independent application inter- 
face as to whether the digital signature is authentic. 

43. A method as recited in claim 39, wherein the per- 
forming step comprises encrypting data according to the 
following steps: 45 

passing at least a portion of the data from the application- 
independent application interface to the IC card; 

encrypting, at the IC card, the data passed from the 
application-independent apphcation interface using the 
cryptographic key; and 

passing the encrypted data from the IC card back to the 
application- independent application interface. 

44. A method as recited in claim 39, wherein the per- 
forming step comprises decrypting data according to the 
following steps: 

passing at least a portion of encrypted data from the 
appUcation-independent application interface to the IC 
card; 

decrypting, at the IC card, the encrypted data passed from 50 
the application-independent application interface using 
the cryptographic key; and 

passing the decrypted data from the IC card back to the 
application-independent application interface. 

45. A method as recited in claim 39, further comprising 65 
verifying the authenticity of the application-independent 
application interface amd the OC card to each other. 
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46. A method as recited in claim 39, further comprising: 
supplying the request for a cryptographic function from 

the application to a cryptographic application program 
interface (CAPI); 

selecting a cryptography service provider (CSP) to per- 
form the requested cryptographic function; 

establishing data communication between the CAPI and 
the CSP; 

establishing data communication between the CSP and 
the IC card; and 

performing the cryptographic function cooperatively 
between the CSP and the IC card using the crypto- 
graphic key stored on the IC card without exposing the 
cryptographic key from the IC card. 

47. A method as recited in claim 46, ftirther comprising: 
verifying authenticity of the CSP to the CAPI. 

48. A method as recited in claim 46, further comprising: 
verifying authenticity of the CSP and the IC card to each 

other. 

49. A method for personalizing contents on an integrated 
circuit (IQ card from a computer according to a user's 
preferences, the method comprising the following steps: 

interfacing the IC card to the computer with an 
application-independent application interface execut- 
ing on the computer; 

presenting a user interface on the computer to the tiser as 
part of the execution of the appUcation interface; 

initializing the IC card using the user interface; 

configuring the IC card, using the user interface, to 
include cryptographic resources and non-cryptographic 
resources; and 

managing the cryptographic and non-cryptographic 
resources that are maintained on the IC card using the 
user interface. 

50. A method as recited in claim 49, wherein the manag- 
ing step comprises adding resources to, and removing 
resources from, the IC card. 

51. A method as recited in claim 49, further comprising 
the following steps: 

partitioning a memory on the IC card into a private 
storage and a public storage; and 

the configuring step comprises storing some of the 
resources in the private storage and some of the 
resources in the public storage, and establishing a 
passcode for use in accessing the private storage. 

52. A method for conducting secure electronic transac- 
tions comprising the following steps: 

configuring, at a first computing site, a portable multi- 
purpose integrated circuit (IC) card with resources that 
enable the IC card to be used for multiple purposes, the 
resources including a cryptographic key and a certifi- 
cate which can be used for at least one of the multiple 
purposes; 

transporting the multi-purpose IC card from the first 
computing site to a second computing site; 

interfacing the multi-purpose IC card with an application 
interface executing at the second computing site, the 
application interface supporting an application which is 
executing at the second computing site to process data 
for a designated purpose, the application requiring 
transformation of at least a portion of the data accord- 
mg to a cryptographic function, the application having 
a certificate; 

exchanging certificates between the application and the IC 
card to verify authenticity to each other; 
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establishing data communication between the application 
and the IC card through the application interface; 

supplying a request for the cryptographic function from 
the application to the application interface; 

performing the cryptographic function cooperatively 
between the application interface and the IC card using 
the cryptographic key stored on the IC card without 
exposing the cryptographic key from the IC card; 

transporting the IC card from the second computing site 
to a third computing site; 

interfacing the IC card with an application interface 
executing at the third computing site, the application 
interface at the third computing site supporting an 
application which is executing at the third computing 
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site and requires access to a non-cryptographic resource 
on the IC card for another designated purpose; 
establishing data communication between the application 

and the IC card through the application interface; 
making a request torn the application for the non- 
cryptographic resource on the I C card; and 
fulfilling the request for the non-cryptographic resource. 
53. A method as recited in claim 52 wherein the applica- 
tion at the third computing site requests access to an asset 
maintained on the IC card and the fulfilling step comprises 
supplying the asset from the IC card to the application at the 
third computing site. 

♦ * ♦ ♦ ♦ 
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On the title page, item 

[75] Inventors: Doug Barlow; Blair Dillavay, both of 
Redmond; Barbara Fox, Seattle; Terry 
Lipscomb, Belle vue; Terence Spies, 
Kirkland, all of Wash. 



Attest: 



Attesting Officer 



Signed and Sealed this 
Twenty-seventh Day of March, 2001 

NICHOLAS P.CODia 

Actinf^ Director of the United States Patent and Trademark Office 
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